Circuit designs are typically created in modular fashion. That is, each subsystem of the circuit design can be independently implemented as a module, for example, in a hardware description language (HDL) or within another tool such as a high level modeling system that operates at a higher level of abstraction. As an example, many modules can be imported or incorporated into a circuit design in the form of an “Intellectual Property (IP) core” or simply “core.”
Generally, a core refers to a pre-designed, programmatic description of hardware that performs a particular function. A core can be specified as an HDL file or files, as a bitstream that programs a programmable integrated circuit device (IC), whether fully or partially programmable, as a netlist, or the like. Alternatively, a core can include source code or schematics that describe the logic and connectivity of a portion of a circuit design. Typical cores can provide digital signal processing (DSP) functions or other mathematical functions. Other examples of cores can implement more complex circuit components or subsystems such as memories, storage elements, or processors. Some cores include an optimally floorplanned layout targeted to a specific family of ICs. Cores can also be parameterizable in that the user may enter parameters to activate or change certain functionality of the core.
When importing a module into a circuit design, a designer must properly connect that module to the circuit design into which the module is being imported. This process typically involves the user manually mapping each port of the module to a complementary port of the circuit design. The time and complexity of this process is dependent upon the number of interfaces in the module and the number of ports within each respective interface.
Modern implementation tools do provide some assistance in this regard, but are unable to effectively process modules that include more than one interface of the same type. Moreover, in order for such a tool to handle interfaces correctly, the interface of the module must strictly adhere to established naming conventions for ports and interfaces alike. That is, if one names ports in a way that deviates, in any respect, from the exact name that is expected by the implementation tool, and which is hard coded in the implementation tool, the implementation tool becomes confused and fails. Accordingly, these tools presently offer little in the way of flexibility.